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A  RANGE-DEPENDENT  TRANSMISSION  LOSS  DATABASE  APPLICATION: 


Countermeasures  Assessment  Simulation  at  NRaD 


1.0  OVERVIEW 

Simulation  models  are  widely  used  throughout  the  U.S.  Navy.  Modeled  Antisubmarine 
Warfare  (ASW)  engagements  often  involve  multiple  targets  and  receivers  with  dynamically  changing 
geometries.  It  follows  that  the  speed  at  which  computations  can  be  performed  is  an  important  aspect 
and  a  desired  feature  of  any  simulation  scenario.  A  realistic  goal  is  1:1  real  time.  This  goal  suggests 
that,  for  the  ASW  engagement,  it  is  beneficial  to  precompute  as  many  of  the  terms  in  the  sonar 
equation  as  possible.  It  follows  that  a  database  of  modeled  values  of  transmission  loss  (TL),  a 
critical  term  in  the  sonar  equation  (and  one  which  is  difficult  to  compute  within  the  timeframe 
desired)  would  find  widespread  application  in  ASW  simulations. 

Our  goal  for  this  project  was  to  produce  a  TL  database  by  running  the  complex  physics  models, 
and  then  properly  cataloging  and  storing  the  output  for  immediate  retrieval  and  use.  This  would 
then  allow  a  modeled  engagement  to  proceed  in  a  timely  manner  through  effective  use  of  these 
“look-up  tables.” 

Originally  we  were  tasked  to  provide  TL  tables  in  ASCII  form,  formatted  in  a  table  for  delivery 
on  a  9-track  tape  in  a  format  compatible  with  the  DEC*  VAX  computer.  The  Naval  Research 
Laboratory  (NRL)  VAX  computer  was  used  extensively  for  generating  the  initial  set  of  TL  tables 
for  the  Naval  Command,  Control  and  Ocean  Surveillance  Center  (NRaD).  Our  early  approach  was 
based  on  the  use  of  range-independent  acoustic  models  (i.e.,  those  that  assume  a  single-profile, 
flat-bottom  environmental  input). 

Subsequently,  NRL  oceanographers  presented  arguments  concerning  the  increased  fidelity  inherent 
in  using  range-dependent  acoustic  models.  In  addition,  NRaD’s  requirement  for  increased  geographic 
coverage  (eventually,  global)  was  identified.  The  revised  tasking  pointed  to  rising  computer  and 
storage  costs  on  the  VAX  mainframe.  This,  in  turn,  suggested  that  software  be  developed  to  run  on 
desktop  personal  computers  (PC).  Computer  storage  problems  were  overcome  with  the  purchase  of 
relatively  inexpensive  mass  storage  devices  for  PCs.  Use  of  the  VAX  mainframe  was  limited  to  the 
following: 

(1)  Input — environmental  database  extractions  were  made  on  the  VAX;  subsets  of  the  global 
databases  on  the  VAX  were  transported  via  Ethernet  onto  Bernoulli  cartridges  and  staged  for 
providing  inputs  to  the  acoustic  model  on  the  PC. 

(2)  Output — output  files  were  passed  to  the  VAX  to  be  formatted  for  delivery. 
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Efforts  were  made  to  stay  abreast  of  new  PC  hardware  developments: 

(1)  Memory  boards  and  math  coprocessors  for  effective  use  of  RAM  were  upgraded,  and  increased 
computing  power  was  increased. 

(2)  Ethernet  was  installed  for  communication  with  the  mainframe;  and 

(3)  Optical  storage  technology. 

Several  specialized  software  developments  were  undertaken  to  support  this  project.  Software 
used  to  conduct  quality  control  on  the  output  using  screen  colorgraphic  displays  was  especially 
innovative.  Also,  a  batch  file  scheme  developed  in-house  significantly  automated  the  process  of 
running  tens  of  thousands  of  model  runs.  Retrieval  software  was  developed  to  run  on  both  the  VAX 
mainframe  (for  NRaD’s  use)  and  the  desktop  PC. 

A  simplified  description  of  the  process  starts  with  the  overall  planning  of  the  project  and  layout 
of  the  acoustic  provinces.  We  perform  environmental  database  extractions  using  INGRES  software  on 
the  VAX  mainframe  computer.  The  files  are  transferred  to  the  PC  utilizing  EATS  software  modules. 
Then  the  acoustic  model  processing  used  the  range-dependent  Navy-standard  model  ASTRAL 
(ASEPS*  transmission  loss)  under  control  of  the  in-house  developed  batch  file  scheme.  The  final 
product  is  then  properly  cataloged  and  archived  on  the  PC  and  transferred  to  the  VAX  for  delivery. 

Although  conventional  thinking  might  have  said  that  it  is  not  feasible  to  model  propagation  loss 
for  every  10°  look  direction  for  many  combinations  of  source  depth/receiver  depth/frequency  for 
scenarios  in  all  of  the  world’s  oceans,  this  project  has  demonstrated  that  such  a  massive  computational 
effort  can  be  done,  and  is  being  done,  given  plenty  of  forethought,  good  science,  and  an  abundance 
of  automation.  At  the  current  rate  of  production,  the  resolution  of  the  TL  database  averages  one  set 
of  range-dependent  TL  model  runs  (i.e.,  one  “node”)  every  1.5°  x  1.5°  square. 

2.0  BACKGROUND 

The  Naval  Command,  Control  and  Ocean  Surveillance  Center  (NRaD),  San  Diego,  CA,  has 
been  substantially  involved  in  the  development  and  use  of  the  wargaming  and  simulation  models 
that  are  widely  used  throughout  the  Navy.  The  database  documented  in  this  report  is  the  result  of 
the  environmental  acoustic  (EVA)  support  provided  by  NRL  for  the  latest  in  NRaD’s  simulation 
modeling  efforts. 

2.1  Early  Beginnings — A  Related  Project 

NRaD  modelers  were  developing  the  Warfare  Environment  Simulator  (WES)  in  1981-82  when 
they  turned  to  the  Fleet  Numerical  Oceanography  Center  (FNOC)  in  Monterey,  CA,  for  EVA 
support.  The  FNOC  special  projects  team  generated  a  database  comprised  of  thousands  of  the  Fast 
Asymptotic  Coherent  Transmission  (FACT)  model  TL  tables  and  hundreds  of  ship  helicopter  acoustic 
range  prediction  system  (SHARPS)  model  active  sonar  range  predictions.  These  modeled  data  were 
used  in  WES  and  subsequently  became  the  “ocean  model”  for  the  Interim  Battle  Group  Tactical 
Trainer  (IBGTT)  and  the  Research  and  Evaluation  for  Systems  Analysis  (RESA)  model/tool.  When 
last  encountered  (1989,  at  the  Naval  Postgraduate  School),  the  RESA  was  still  using  this  database 
of  modeled  ocean-acoustic  parameters. 
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2.2  Countermeasures  Assessment  System  (CMAS) 

NRaD  recently  developed  this  multiwarfare  area  simulation  model.  The  purpose  of  CMAS 
is  to  support  the  Chief  of  Naval  Operations’  research  requirements.  For  EVA  support,  NRaD  turned 
to  NRL. 


2.3  A  Range-Independent  TL  Database  for  CMAS 

The  first  test  for  the  NRL  modelers  was  to  update  the  data  in  the  “ocean  model,”  which  was 
developed  at  FNOC  for  WES.  [Note:  Both  NRL  coauthors/modelers  were  previously  stationed  at 
FNOC.)  These  TL  values  were  modeled  using  the  new  Navy-standard  range-independent  TL  model 
(RAYMODE)  and  were  provided  for  a  limited  number  of  ASW  Prediction  Areas  (i.e.,  in  the  FNOC 
format).  We  used  the  NRL-developed  VAX/VMS  ASW  Model  Processing  Network  (VAMPNET) 
for  our  environmental  databases  and  acoustic  models  (Rapp  1987)  to  automate  the  labor-intensive 
tasks  of  building  acoustic  model  input  decks.  Since  this  processing  allowed  for  only  one  frequency, 
source  depth,  and  receiver  depth  geometry  for  each  range-independent  model  execution,  extensive 
use  of  VAMPNET  was  necessary  to  produce  the  numerous  model  executions  efficiently. 

2.4  The  First  Range-Dependent  TL  Database  for  CMAS 

Once  it  was  clear  that  the  NRL  modelers  could  mass-produce  modeled  acoustic  products  in  a 
timely  and  cost-efficient  manner  (and  in  a  compatible  format),  the  task  turned  toward  increasing  the 
fidelity  of  the  inputs  to  the  CMAS  simulation.  The  NRL  modelers  proposed  that  we  reject  the  idea 
of  limiting  CMAS  to  an  approach  based  on  range-independent  calculations.  We  proposed  that  we, 
as  a  community,  “graduate”  to  the  next  level  of  sophistication:  range-dependent  modeling  (Northridge 
1990).  The  difference  is  an  order-of-magnitude  increase  in  the  complexity  of  the  EVA  descriptions. 
Range-dependent  descriptions  of  the  ocean  environment  involve  multiple  radials  of  great  circle  path 
sections  (known  as  “tracks”  in  the  VAMPNET  system)  vice  the  single  environment  (point)  processing 
implied  by  range-independence.  The  important  technical  issue  at  this  point  in  the  process  was 
efficiency.  Could  such  a  large  database  be  built  in  a  timely,  reproducible,  quality-controlled, 
cost-efficient  manner? 

For  demonstration  purposes,  NRL  developed  a  procedure  in  which  a  range-dependent  section 
of  the  ocean  could  be  represented  by  laterally  homogeneous  assumptions.  That  is  to  say,  the 
range-varying  oceanographic  and  bathymetric  inputs  were  extracted  in  one  direction  (in  this  case, 
a  south-north  section;  see  Fig.  la)  and  not  allowed  to  vary  laterally  (west-to-east).  The  areas 
represented  covered  100  nmi  x  100  nmi.  Eleven  nodal  positions  were  selected  (Fig.  lb).  The 
environmental  description  as  it  was  extracted  had  the  correct  start-point  and  end-point  for  the  first 
node  only.  The  data  were  “rearranged”  appropriately  for  the  model  runs  at  the  other  nodes. 
Figure  lc  illustrates  this  sampling  for  the  middle  node.  At  each  node,  range-dependent  model  runs 
were  made  for  a  number  of  radials  (Fig.  Id).  Radial  TL  information  from  a  (source)  node  was 
converted  from  spherical  to  rectangular  coordinates  to  build  a  TL  grid  table  with  a  TL  value  at  each 
x,  y  point  on  a  grid  having  1-nmi  resolution  (i.e.,  these  were  101  x  101  matrices).  This  was  done 
for  each  of  the  1 1  node  locations.  The  grid  tables  were  then  consolidated  into  a  single  file  called 
a  database.  One  of  these  databases  existed  for  each  source  depth/receiver  depth/frequency  combination 
and  for  each  new  environment  (e.g.,  different  seasons).  Because  of  the  lateral  homogeneity,  the  TL 
field  for  the  same  position  on  the  y-axis  but  for  different  positions  along  the  x-axis  are  just 
translations  of  the  TL  grid  calculated  for  that  (first-column)  node.  Although  this  calculation  was 
handled  by  the  software  (Soileau  1988)  that  extracted  TL  values  from  the  TL  database  (as  opposed 
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Fig.  1  —  (a)  Sound  velocity  environment  input  cross  section,  (b)  ocean  OPAREA  layout,  (c)  bidirectional 
segmentation  of  sound  velocity  input  cross  section,  and  (d)  nodal  radial  layout 


to  translating  these  matrices  and  storing  many  large  files),  the  procedure  gave  the  simulation 
modeler  the  “appearance”  of  a  database  where  the  TL  from  target  to  sensor  was  a  function  of  range 
and  bearing  anywhere  on  the  101  x  101  playing  field. 

The  acoustic  model  used  was  ASTRAL.  It  is  capable  of  treating  an  environment  where  ocean 
depth,  sound  speed  profile,  and  geoacoustic  parameters  vary  as  a  function  of  range.  In  addition, 
ASTRAL  is  designed  to  process  multiple  frequencies,  as  many  as  six  (6),  with  each  model  execution. 
NRL  developed  new  methods  of  output  storage  featuring  a  newly  designed  binary  format.  Retrieval 
software  was  developed  allowing  the  user  to  select  and  retrieve  TL  for  a  source  located  at  any  node 
point  along  the  acoustic  environment  section.  NRL  also  developed  a  user-friendly  (menu-driven) 
method  to  pictorially  display  the  numerous  databases  and  environment  sections.  Program  SHDPLT 
(Wooten  et  al.  1987)  displays,  in  contour  or  in  color  format,  a  two-dimensional,  16-color  DISSPLA 
plot  of  an  i-by-j  matrix  of  data;  this  format  allows  NRL  analysts  to  perform  quality  control  easily 
at  almost  any  step  of  the  database's  build-and-access  procedure. 

This  ultra-efficient  initial  approach  was  applied  to  a  particular  sonobuoy  search  study  (Wilcox 
and  Delgado  1988)  and  worked  well.  Eventually,  however,  the  assumptions  of  lateral  symmetry  for 
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frontal  regions  and  bathymetric  slopes  and  seamount  chains  would  require  too  many  restrictions. 
The  approach  was  determined  to  be  too  limited  for  NRaD’s  requirement  for  global  ocean  descriptions. 
We  were  forced  to  develop  an  alternative  approach. 

3.0  DISCUSSION 

At  its  most  basic  level,  the  large-scale  simulation  requirement  being  tackled  by  this  effort  was 
to  provide  the  TL  input  to  the  sonar  equation  for  combinations  of  sensors  and  targets  whose 
locations  could  be  anywhere  on  the  “field  of  play.”  Our  TL  data  would  be  produced  in  radial  form, 
representing  the  energy  lost  as  it  radiates  out  from  the  source.  [A  caveat  to  that  assertion  is  cited 
in  Sec.  4.2.]  The  center  point  is  referred  to  as  a  “node.”  Let  us  suppose  that  the  “field  of  play”  is 
a  grid  whose  resolution  is  1  nmi  x  1  nmi.  To  make  a  new  model  calculation  at  the  resolution 
equivalent  to  the  scale  at  which  we  knew  the  source  location  (say,  1  nmi)  would  be  a  Herculean 
feat;  it  would  also  be  overkill.  Instead,  we  formulated  the  requirement  in  terms  of  a  distribution  of 
nodes  in  such  a  way  that,  for  every  gridpoint,  there  is  a  node  nearby  that  is  representative  of  its 
acoustic  conditions.  One  could  then  consider  the  collection  of  gridpoints  that  were  represented  by 
the  same  node  to  be  a  “province.” 

3.1  Province  Methodologies 

There  have  been  long-standing  projects  in  the  acoustics  community  to  section  the  ocean  into 
environmentally  homogeneous  areas,  called  provinces.  Previous  to  range-dependent  modeling, 
methodologies  for  provincing  the  ocean  were  based  upon  single  environmental  parameters.  For 
example,  the  Naval  Oceanographic  Office  (NAVOCEANO)  ASW  area  charts  (NWPCB  series)  were 
based  upon  areas  of  similar  bottom  conditions.  Province  Generalized  Digital  Environmental  Model 
(GDEM)  used  the  convergence  zone  distances  from  RAYMODE  as  a  measure  of  when  the  sound 
velocity  profile  was  significantly  different.  Since  (as  far  as  we  know)  this  project  is  the  first  attempt 
to  systematically  use  the  output  of  range-dependent  TL  models  in  the  computer  environment  of  a 
large-scale  simulation  in  a  systematic  way,  we  needed  to  invent  a  method  that  would  represent  any 
collection  of  contiguous  gridpoints  that  have  range  and  azimuthally  varying  environments  that  are 
acoustically  similar — and  call  that  collection  of  points  a  province.  Another  way  of  saying  it  is  that 
the  local  area  (province)  must  share  similar  nonhomogeneous  characteristics. 

A  preliminary  analysis  of  node  distributions  and  provincing  schemes  was  conducted  by  highlighting 
features  and  boundaries  of  the  ocean  acoustic  environment.  GDEM  temperatures  were  contoured  for 
a  study  area  (surface,  100  m,  200  m,  and  400  m);  sonic  layer  depths  were  contoured;  and  bathymetric 
data  from  digital  bathymetric  database,  ver.  5  (DBDB5),  a  Navy-standard  database,  were  contoured. 
Since  the  spatial  variability  of  the  acoustic  environment  is  a  function  of  changes  in  the  sound 
velocity  profiles,  the  geoacoustics,  and  the  bathymetry,  correlation  coefficients  were  generated  and 
analyzed.  The  results  determined  bathymetry  to  be  the  primary  factor  in  defining  acoustic  homogeneity 
within  the  region.  However,  there  is  a  caveat:  The  oceanography  could  well  have  been  more  of  an 
indicator  of  the  spatial  variability  of  the  acoustic  environment,  except  that  the  GDEM  database  is 
a  smoothed  climatological  field  that  does  not  represent  well  the  high  gradient  features  (fronts  and 
eddies)  in  the  ocean. 

3.2  The  Topography  Analogy 

We  proceeded  to  divide  a  given  operations  area  into  individual  provinces  with  the  following 
rationale.  Imagine  a  sensor  located  on  top  of  a  mountain;  we  assume  the  far  horizon  can  be  seen 
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unobstructed  in  all  directions.  Everywhere  on  top  of  that  mountain,  the  360-degree  picture  is  the 
same.  If,  for  instance,  one  moved  down  the  northern  slope,  then  the  view  to  the  south  would  change 
rapidly.  For  a  system  that  provides  representations  of  that  view,  the  requirement  would  be  to 
provide  more  new  pictures  as  one  moves  in  that  direction.  Similar  logic  would  apply  to  regions  of 
slope.  The  view  of  the  valley  below  would  be  similar  for  many  miles  if  the  same  elevation  walking 
along  a  ridge  was  maintained.  If  one  went  in  an  orthogonal  direction  (down  the  hill  or  up  over  the 
top  of  the  ridge),  then  the  view  would  change  radically  in  just  a  short  distance.  In  the  traditional 
approach  to  acoustic  province  determination,  areas  that  grouped  together  the  average  acoustic  conditions 
were  designed.  Using  this  new  approach,  we  outlined  areas  where  the  most  rapid  changes  occur  and 
define  them.  Essentially,  a  distinct  view  (a  node)  is  needed  for  the  top  of  a  hill  and  separate  distinct 
nodes  for  each  different  downhill  direction.  For  each  of  these  areas,  a  single  location  (usually  the 
geometric  center  of  the  province)  is  selected  to  represent  the  environmental  conditions  of  the  entire 
province  area. 

Figure  2  is  a  computer-generated  bathymetric  chart  of  a  subarea  of  the  Norwegian  Sea.  The 
bathymetry  is  from  DBDB5.  Three  different  areas  are  outlined  as  provinces.  Note  the  relatively  flat 
area  of  the  Voring  Plateau.  A  representation  of  the  acoustic  characteristics  for  any  source  node 
located  over  this  bathymetric  feature  might  be  expected  to  be  valid  over  the  entire  plateau — in  this 
case,  bottom-interacting  energy  that  fills  the  whole  water  column.  But  the  analyst  might  assume 
that  a  characterization  attached  to  this  province  should  be  to  allow  the  acoustic  energy  to  “escape” 
the  confines  of  the  plateau  and  to  enter  the  sound  channel  that  is  available  in  the  deeper  water. 
Since  the  plateau  is  so  large,  we  assume  that  acoustic  paths  across  the  breadth  of  this  feature  would 
incur  enough  bottom  interaction  to  “kill”  the  energy  before  it  could  “escape.”  So  we  outline  the 
only  northern  portion  and  define  it  as  province  A.  Along  the  northern  slope  of  the  Voring,  we 


Fig.  2  —  Norwegian  Sea  nodal  plan 
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expect  radically  different  acoustic  environments  in  the  uphill  and  the  downhill  directions.  Since  the 
gradient  is  quite  uniform,  we  expect  a  fairly  constant  “view”  for  many  miles  in  the  east-west 
direction.  We  define  province  B  as  being  much  wider  than  it  is  tall,  and  we  assume  that  the  acoustic 
environment  would  not  appreciably  change  from  one  grid  cell  to  the  next  within  the  province  area. 
Smaller  area  provinces  are  required  as  one  approaches  areas  of  rapid  bathymetric  change  as  seen 
along  the  western  horn  of  the  Voring  slope  (province  C).  We  applied  this  same  logic  over  entire 
ocean  operation  areas  (OPAREA)  to  define  provinces  with  similar  characteristics.  This  procedure 
allows  one  node  to  represent  the  entire  province  area. 

3.3  The  Essence  of  a  Range-Dependent  TL  Database 

Figure  3  illustrates  the  results  of  modeling  TL  using  the  provincing  scheme  described  above. 
Propagation  loss  is  scaled  according  to  the  color  bar  shown.  Province  A,  up  on  the  plateau,  displays 
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similar  acoustic  propagation  (bottom  limited)  out  in  all  directions  to  the  edge  of  the  plateau 
(Fig.  3a).  A  little  energy  does  make  it  into  the  sound  channels  off  the  nearest  edges  (to  the  north 
and  west).  Province  B,  on  the  northern  slope  (Fig.  3b),  shows  that  the  acoustic  energy  does  not 
propagate  well  back  ap  the  slope  to  the  south,  so  there  would  be  little  chance  of  detecting  a  target 
situated  over  that  slope  using  a  sensor  located  on  the  Voring  Plateau.  Province  C  (Fig.  3c),  on  the 
western  horn  siope,  shows  similar  upslope  propagation  patterns;  this  time  the  blockage  caused  by 
the  plateau  is  to  the  east. 

Two  factors  combine  to  make  this  database  essentially  new  technology.  (Although  each  factor 
has  been  available  in  the  modeling  community  for  a  number  of  years,  this  is  the  first  time  [to  our 
knowledge]  they  have  been  used  together  in  a  single  product.)  Building  a  database  using  the 
provincing  scheme  aids  the  user  in  understanding  the  spatial  variability  of  the  acoustic  environment. 
Comparing  Figs.  3b  and  3c,  the  propagation  differences  between  the  northern  and  western  slopes  of 
the  Voring  Plateau  can  be  seen.  The  second  factor  is  the  range-dependent  modeling.  A  comparison 
of  Figs.  3b  and  4  shows  the  range-dependent  vs.  range-independent  results  for  province  B.  Obviously, 
one  would  not  have  the  same  appreciation  for  the  dynamics  of  the  acoustic  environment  if  one  had 
to  rely  on  the  range-invariant  results  alone:  yet  the  community  has  been  relying  on  this  simpler 
approach  until  now. 


4.0  DATABASE  DESIGN 
4.1  Definition 

The  word  database  is  frequently  used  to  refer  to  a  file  or  a  group  of  files  that  may  or  may  not 
be  well  organized.  Strictly  speaking,  a  database  is  a  collection  of  logically  related  files.  This  use 
of  the  word  logically  refers  not  to  the  user’s  perception  of  the  files  or  their  use,  but  to  the  unique 
structure  of  the  files  that  allows  a  computer  program  to  access  related  data  correctly  from  related 
files. 


Fig.  4  —  Norwegian  Sea  range-independent  TL.  source 
depth  18  m.  receiver  depth  18  m,  summer,  150  Hz, 
province  B 
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Within  this  collection  of  files  called  a  database,  each  file  contains  various  records.  Each  record 
in  each  file  can  be  uniquely  identified  by  the  use  of  a  “key.”  A  key  is  a  field  whose  value  uniquely 
identifies  each  record.  In  simple  scenarios,  such  as  the  environmental  databases  used  as  input  to  this 
process,  records  of  data  with  the  same  key  are  logically  related  regardless  of  the  file  in  which  they 
are  contained.  For  example,  DBDB5  contains  latitude,  longitude,  and  a  depth  value.  GDEM  contains 
latitude,  longitude,  and  a  sound  velocity  profile.  Thus,  by  using  the  latitude  and  longitude  as  the 
unique  key,  a  computer  program  could  extract  a  sound  velocity  profile  with  the  appropriate  depth. 

Strictly  speaking,  the  collection  of  TL  files  documented  here  is  not  a  database.  There  is  no  key 
within  the  files  that  uniquely  identifies  the  data.  All  the  knowledge  about  the  contents  of  these  files 
is  contained  in  the  filename.  This  is  why  it  is  so  important  with  this  database  to  create  and  document 
a  complete,  correct,  and  consistent  filename  convention. 

This  report  documents  our  methodology  for  putting  modeled  TL  output  in  a  format  that  will  be 
used  as  a  “look-up  table”  for  such  applications  as  wargames  and  simulations  of  naval  operations. 
Specifically,  our  methods  for  storing  the  output,  for  retrieving  the  processed  data,  and  for  quality 
controlling  the  data  were  originally  developed  for  use  on  the  VAX  computer.  To  reduce  costs  for 
this  project,  these  methods  were  converted  to  software  that  operated  on  IBM-compatible  PCs.  The 
CM  AS  database  was  built  entirely  on  the  PC,  and  the  output  was  transferred  to  the  VAX  using 
Ethernet  and  delivered  via  9-track  tapes  (later,  via  optical  disks). 

4.2  Contents  of  the  CMAS  TL  Database 

The  CMAS  TL  database  is  initially  generated  in  ASCII  tabular  form  that  contained  TL  for  each 
node  and  each  season  for  three  source/receiver  geometries,  eight  frequencies,  and  36  radials  with 
an  output  resolution  along  a  radial  of  1-nmi  increments  for  300  nmi.  The  ASCII  form  of  the 
database  was  then  compressed  into  a  binary  direct  access  (BDA)  format  for  ease  of  storage  and 
rapid  retrieval  of  information. 

4.2.1  CMAS  TL  Database — Nodes 

The  CMAS  TL  database  currently  contains  1844  nodes  in  the  North  Atlantic  and  2003  nodes 
in  the  North  Pacific  (Fig.  5). 

4.2.2  CMAS  TL  Database — Seasons 

The  CMAS  TL  database  currently  contains  data  for  summer  and  winter. 

4.2.3  CMAS  TL  Database — Source/Receiver  Geometries 

Through  discussions  with  the  sponsor,  it  was  decided  that  one  shallow  target  (source)  and  one 
deep  source  would  be  modeled.  Also,  one  shallow  receiver  and  one  deep  receiver  would  be  modeled. 
The  discrete  depths  selected  for  model  depth  geometry  inputs  are  as  follows: 

Shallow  =  18  m  (-60  ft) 

Deep  =  381  m  (-1250  ft) 

The  CMAS  modeler  will,  of  course,  have  targets  and  sensors  at  more  than  just  these  two 
depths;  however,  that  is  an  implementation  issue  for  NRaD.  A  description  of  one  of  the  methods 
discussed  follows.  For  environments  with  substantial  surface  ducts,  SHALLOW  would  represent 
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any  source  or  receiver  shallower  than  the  sonic  layer  depth,  and  DEEP  would  be  used  lor  source 
or  receiver  deeper  than  the  sonic  layer  depth.  The  Program  SVPANA  (Secs  6  and  7)  identifies  the 
sonic  layer  depth  in  each  province  and  is  provided  for  this  purpose. 

For  those  provinces  shallower  than  381  m,  the  DEEP  depth  was  adjusted  shallower  than  the 
bottom  depth  to  keep  the  sensor  within  the  water  column  (  —  10  m  above  the  DBDB5  depth) 

Figure  6  identifies  the  four  source  receiver  geometries  required  by  the  ('MAS  simulation. 

(1)  SHALLOW  Source  to  SHALLOW  Receiver  (SS) 

(2)  SHALLOW  Source  to  DEEP  Receiver  (SD) 

(3)  DEEP  Source  to  DEEP  Receiver  (DD) 

(4)  DEEP  Source  to  SHALLOW'  Receiver  (DS) 


Fig.  6  —  Model  geometry  plan 


The  careful  reader  may  have  noticed  that  the  database  was  described  previously  as  having  only 
three  source-receiver  geometries,  namely,  ( 1 )— (3).  This  description  is  true.  The  fourth  case  is 
implemented  for  CMAS  simulations  by  invoking  acoustic  reciprocity  (and  using  type  (2)  TL  from 
the  node  corresponding  to  the  location  of  the  SHALLOW  Receiver).  An  example  is  described 
in  the  appendix. 

4.2.4  CMAS  TL  Database — Frequencies 

The  CMAS  database  currently  contains  TL  for  the  following  frequencies:  25,  50,  150,  315,  630, 
900,  1250,  and  1600  (Hz). 

4.2.5  CMAS  TL  Database — Radials 

The  environmental  data  were  extracted,  and  the  ASTRAL  model  was  run,  for  36  radials  at  10° 
intervals  from  0  to  350°. 


4.3  Using  Multiple  Radials 

Range-dependent  TL  modeling  is  not  new.  Software  to  extract  the  required  environmental 
^  inputs  along  a  great  circle  path  (also  called  a  track,  a  radial,  or  a  section)  by  reaching  into  the  grid 

format  (sound  velocity  profile,  bathymetry,  and  geoacoustic)  databases  has  also  been  available  for 
a  few  years.  The  relatively  new  software  is  the  NRL  program  that  extracts  multiple  environmental 
sections  at  user-specified  angle  steps  and  ranges  about  a  particular  location.  A  single  section  (track) 
of  range-dependent  environmental  parameters  is  combined  with  tracks  from  other  radials — all  extracted 
from  a  single  location.  This  defines  the  environment  in  all  directions  from  that  central  point  and 
•  determines  a  circular  area  of  coverage  (STAR;  the  output  TL  plots  have  also  been  referred  to  as 

“wagon  wheels").  Each  STAR,  although  generated  at  a  particular  location  within  a  province,  defines 
the  environment  for  the  entire  province. 
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Another  NRaD  implementation  issue  involves  the  interpolation  necessary  to  arrive  at  the  “correct” 
TL  for  a  target  lying  at  a  particular  bearing  and  range  from  a  sensor.  Obviously,  the  accuracy  of 
that  process  is  a  function  of  the  number  of  radials  (36)  and  the  great  circle  distance  range  steps 
(1  nmi)  selected  at  the  time  the  database  is  built. 

4.4  Mapping  and  Charting  Support 

As  discussed  in  Sec.  3,  the  provincing  scheme  required  that  we  identify  areas  of  environmental 
differences,  especially  high-gradient  bathymetric  differences.  Large-scale  bathymetry  charts  were 
needed.  The  chart  for  the  original  Norwegian  Sea  OPAREA  study  was  developed  by  splicing  pieces 
of  four  NAVOCEANO  charts.  However,  the  extent  of  the  final  CMAS  database  (global  coverage) 
required  that  a  more  efficient  method  be  found  for  building  these  planning  charts.  NRL  workstation 
experts  developed  a  method  of  generating  large-scale  charts  using  the  same  bathymetry  database, 
DBDB5,  as  was  used  for  the  ASTRAL  TL  computations.  These  products  were  desktop-sized 
(2  ft  x  3  ft  or  larger)  charts  usually  covering  15°  of  latitude  and  20°  of  longitude.  Printed  on  these 
charts  was  a  map  overlay  grid  with  a  resolution  of  1/4°  latitude  x  1/2°  longitude.  This  grid  was  used 
to  define  the  province  boundaries  at  that  resolution.  (Note:  At  the  latitude  of  the  first  prototype 
OPAREA  that  we  tackled — the  Norwegian  Sea  at  60°N  this  grid  resolution  is  15  nmi  x  15  nmi.) 
Contiguous  cells  of  the  grid  that  were  deemed  acoustically  similar  defined  the  individual  nodal 
province  areas. 

4.5  Node  Nomenclature 

A  naming  convention  was  required  to  define  geographic  points  and  areas  used  in  generating 
this  database  (and  for  possible  future  use  in  other  environmental  studies).  We  needed  the  nomenclature 
convention  to  fit  within  the  constraints  of  DOS  file  character  limitations.  We  also  wanted  it  to 
provide  a  rational  approach  for  embedding  geographic  information  so  that  the  database  contents 
would  be  "tagged”  to  any  one  of  a  large  number  of  locations.  Also,  the  plan  was  to  build  a  node 
location  program  (FINDER)  that  had  to  correlate  a  particular  location  (latitude/longitude)  to  a 
particular  filename  (where  that  file  contained  the  data  for  the  appropriate  individual  node).  A  naming 
convention  was  designed  utilizing  the  eight  characters  of  a  DOS  filename  (the  three  characters  of 
the  DOS  file  extension  indicate  file  type). 

The  CMAS  database  nomenclature  convention  is  described  below.  Using  this  convention,  the 
FINDER  program  was  built  (Sec.  8).  The  nomenclature  convention  has  four  parts: 

•  A  procedure  to  specify  database  type  (DETERMINISTIC  or  RANDOM). 

•  An  external  indexing  scheme  to  locate  the  rectangular  area  on  a  global  coordinate  system. 

•  An  internal  scheme  to  define  subareas  or  point  locations  within  the  rectangular  area. 

•  A  method  to  identify  the  season. 

4.5.1  Database  Type 

The  first  character  (Cl)  defines  the  database  type.  There  are  multiple  implementations  possible 
for  each  of  the  two  basic  database  methods:  deterministic  or  random.  A  deterministic  scheme 
implies  that  the  data  are  evenly  distributed  spatially  and  that  they  enjoy  a  1:1  correlation  with  the 
grid  cells  in  the  database  (which  have  a  user-defined  resolution).  We  envisioned  that  the  deterministic 
scheme  would  be  utilized  to  build  range-independent  TL  databases  that  can  be  adjusted  in  resolution 
by  defining  the  appropriate  grid  size.  (Note:  A  range-independent  TL  database  was  built  on  a  coarse 
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resolution  [5°  grid]  featuring  this  deterministic  database  scheme  for  the  purpose  of  demonstrating 
this  method.)  A  random  scheme  implies  that  the  data  (i.e.,  the  province  areas)  are  nonuniform  in 
size  and  shape. 

The  CMAS  TL  database  being  documented  here  is  a  randomly  spaced  vice  evenly  spaced 
deterministic  database.  Our  random  designed  database  is  divided  into  large  rectangular-shaped 
ocean  OPAREAs  (10°  of  latitude  x  20°  of  longitude),  each  having  numerous  subareas.  These 
subareas  contain  the  provinces  that  are  irregular  in  size  and  shape  (random).  These  provinces  may 
range  in  size  from  the  smallest  grid-cell  resolution  (the  individual  cell  size  is  1/4°  latitude  and 
1/2°  longitude)  up  to  the  full  size  of  the  subarea  (10°  of  latitude  x  20°  of  longitude).  In  fact,  of  the 
OPAREAs  built  and  delivered  thus  far,  the  smallest  province  is  1  cell;  the  largest  is  121  cells; 
the  average  size  is  18  cells.  On  average,  then,  the  CMAS  TL  database  has  a  resolution  of  1.5°  x  1.5°. 

The  following  table  summarizes  the  two  database  types  and  resolutions  with  which  we  have 
experimented.  Additional  characters  can  be  assigned  as  necessary  to  define  a  scheme  for  a  particular 
application. 


Cl 

Rectangular  Area  (Lat  x  Lon) 

Type 

Coverage 

T 

10°  x  20°  (Fig.  7) 

Random 

Global 

D 

5°  x  5°  (Fig.  8) 

Deterministic 

Global 

4.5.2  Ocean  OPAREA 

The  next  two  characters  (C2  and  C3)  are  used  to  define  the  large  ocean  OPAREAs.  We  designed 
the  database  OPAREAs  to  closely  follow  the  Standard  Navy  Ocean  Area  and  Region  Index  Limits 
published  by  the  Defense  Mapping  Agency  Hydrographic  Center  (DMAHC;  Fig.  7a).  A  global 
system  would  include  databases  of  the  seven  major  ocean  areas: 

1.  NP  North  Pacific  Ocean  (Fig.  7b) 

2.  NA  North  Atlantic  Ocean  (Fig.  7c) 

3.  IO  Indian  Ocean  (Fig.  7d) 

4.  SP  South  Pacific  Ocean  (Fig.  It) 

5.  SA  South  Atlantic  Ocean  (Fig.  7f) 

6.  AR  Arctic  Ocean  (Fig.  7g) 

7.  AN  Antarctic  Ocean  (Fig.  7h) 

4.5.3  External  Index  for  Subareas 

The  next  characters  (C4  and  C5)  are  used  to  define  the  external  index  of  the  reference  latitude 
and  the  reference  longitude,  respectively  for  the  subarea  rectangle. 


Figure  7b  is  the  North  Pacific  (NP  OPAREA)  chart  showing  the  10°  latitude  by  20°  longitude, 
externally  indexed  subareas.  This  OPAREA  was  designed  for  seven  individual  latitude  zones  (0°N 
to  70°N  in  10°  increments)  and  nine  individual  longitude  zones  (I00°E  to  80°W  in  20°  increments) 
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externally  indexed  from  0°N  and  100°E  (every  ocean  OPAREA  external  index  originates  from 
the  southwestern  comer  of  the  individual  OPAREA).  The  numeric  characters  1  through  7  define  the 
latitude  grid  index  zones.  Each  zone  is  listed  in  ascending  order  from  the  index  in  both  northward 
and  eastward  directions.  For  this  case  (NP)  at  0°N/100°E,  the  latitude  grid  index  zones  start  from 
0°N  increasing  northward  in  10°  blocks  and  are  assigned  the  characters  1  through  7,  respectively. 
The  longitudinal  grid  index  zones  start  from  100°E,  increasing  eastward  in  20°  blocks  assigning  the 
numeric  characters  1  through  9,  respectively. 

Figure  7c  shows  the  NA  OPAREA  grid-indexing  scheme.  The  NA  area  is  externally  indexed 
at  0°N/100°W  extending  northward  to  80°N  in  10°  blocks  and  eastward  to  60°E  in  20°  blocks.  This 
system  overlaps  the  NP  grid  from  100°W  to  80°W.  The  overlap  was  necessary  because  the  Gulf  of 
Mexico  is  positioned  in  the  same  longitude  band  as  the  easternmost  part  of  the  North  Pacific  Ocean. 
There  are  similar  overlaps  between  other  OPAREAs. 

For  OPAREAs  originating  in  the  Southern  Hemisphere,  the  databases  will  be  externally  indexed 
the  same  as  those  in  the  Northern  Hemisphere  (all  originate  from  the  southwestern  cor.ier  of  the 
individual  OPAREA).  Each  increments  toward  the  North  Pole  in  10°  block  steps  and  toward  the  east 
in  20°  block  steps. 

4.5.4  Location  Within  the  Rectangle 

Characters  6  and  7  (C6  and  Cl)  are  used  to  provide  intra-rectangle  (sub-subarea)  relative 
location  information.  The  scheme  used  for  a  particular  project  is  chosen  during  the  database  design 
phase  of  the  modeling  project  when  the  OPAREA  directories  are  initially  established.  Two  basic 
types  of  intra-rectangle  indexing  are  addressed  at  this  time: 

•  The  uniform/serial  indexing  convention.  Figure  8  is  an  example  of  a  deterministic  scheme  that 
subdivides  the  NA  OPAREA  externally  indexed  grid  (subarea-NA46)  into  a  1°  by  2°  grid.  One 
nodal  point,  at  most,  can  be  assigned  to  each  sub-subarea  at  the  geometric  center,  which  makes  this 
scheme  appropriate  for  equally  spaced  node  locations.  Boundaries  are  defined  so  the  individual 
sub-subarea  owns  the  southern  and  western  walls. 

•  The  random  indexing  convention  allows  for  the  maximum  flexibility  in  assigning  nodes  (data 
points)  within  a  subarea  rectangle.  This  type  of  indexing  permits  the  user  to  define  the  number  of 
nodes  (provinces)  from  as  few  as  one  to  as  many  as  100  (labeled  00  to  99)  random  areas  within 
the  rectangle  each  of  varying  size.  The  CMAS  database  was  designed  utilizing  the  random  indexing 
convention. 

4.5.5  Season  Indicator 

Character  eight  (C8)  is  used  to  define  the  season  of  the  file.  The  following  alphabetical  characters 
represent  the  seasons: 


S  Summer 
F  Fall 
W  Winter 
P  SPring 
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Fig.  7  —  (c)  North  Atlantic  OPAREA  and  (d)  Indian  Ocean  OPAREA 
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4.5.6  File  Types 

The  file  types  are  determined  from  the  file  extensions  assigned.  This  project  required  four 
different  types  of  files;  a  fifth  was  found  to  be  very  useful.  They  are  listed  below  and  explained 
in  greater  detail  later: 

#  (1)  *.DAT  is  an  ASCII  file  containing  the  TL  output. 

(2)  *.BDA  is  a  binary  direct  access  file  containing  the  TL  in  a  compressed  form  for  better 
storage  and  faster  retrieval  of  information. 

(3)  *.GEO  is  an  ASCII  file  containing  the  model  geometry  information. 

(4)  *.PIX  is  a  saved  picture  element  file  (pixel)  that  can  be  redisplayed  on  the  screen  or  plotted 

w  for  quality  analysis/control. 

(5)  *.ARC  is  the  archived  file  that  contains  all  of  the  above. 


A  representative  filename  follows:  TNA4657P.BDA.  From  the  table  in  Sec.  4.5.1,  we  know 
that  T  denotes  a  random  nomenclature  scheme.  NA  defines  the  ocean  OPAREA  of  the  North 
•  Atlantic  (Fig.  7c).  The  next  two  numbers,  4  and  6,  define  a  subarea  containing  the  island  of  Sicily 

in  the  Mediterranean  Sea  [remember — latitude  is  always  first].  Using  the  random  indexing  conven¬ 
tion,  57  indicates  a  node  number  (a  province)  within  the  subarea  (Fig.  8).  The  province  latitude 
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number  5  indicates  in  a  relative  sense  that  the  node  resides  somewhere  within  the  latitude  band 
of  35°N  to  36°N,  and  the  longitude  number  7  indicates  that  the  node  resides  somewhere  in  the 
longitude  band  14°E  to  16°E.  For  example,  the  island  of  Malta  resides  within  the  area  of  the  band 
intersections  listed.  A  deterministic  scheme  would  have  fixed  the  location  of  the  node  to  the  center 
point  35.5°N/15°E  and  would  have  completely  defined  the  cell.  The  random  scheme  indicates  only 
a  relative  position  within  the  subarea.  Malta  does  not  occupy  the  entire  area  and  is  actually  surrounded 
by  provinces  that  may  either  reside  within  the  same  band  or  extend  to  neighboring  band  area 
intersections.  The  Sicilian  island  land  mass  extends  into  five  sub-subareas  (67,  76,  77,  86,  and  87). 
The  file  extension  name  indicates  this  file  contains  node  TL  data  in  Binary  Direct  Access  format. 


5.0  HARDWARE/SOFTWARE  EFFICIENCIES 

A  primary  concern  for  the  new  TL  database  procedure  was  that  it  be  compatible  with  any  future 
developments.  NRL  considers  the  issue  of  TL  database  construction  to  be  one  of  increasing 
sophistication  as  hardware  and  software  improvements  are  developed  and  become  available.  The 
basic  technology  was  built  around  range-independent  TL  per  ASW  area.  An  intermediate  technology 
was  built  around  range-dependent  TL  with  some  limitations  imposed  (i.e.,  lateral  homogeneity). 
The  ultimate  goal  is  to  obtain  range-dependent  TL  curves  radially  from  every  point  on  a  fine- 
resolution  grid  over  the  entire  OPAREA.  The  roadblocks  to  achieving  this  goal  are  manpower  for 
model  setup,  CPU  costs,  execution  time  to  run  the  models,  manpower  for  model  postprocessing, 
and  the  necessary  hardware  storage  devices  to  house  the  output. 

The  cost  for  VAX  mainframe  CPU  and  storage  for  this  project  was  prohibitive,  so  we  investigated 
the  feasibility  of  running  on  DOS-based  PCs.  New  hardware  developments  in  PC  mass  storage 
devices  (such  as  the  removable  floppy  cartridge  and  optical  disk  devices),  speed-up  boards,  the 
greater  speed  of  the  386  microprocessors,  and  the  use  of  extended  memory  for  random-access 
memory  (RAM)  disk  working  areas  allowed  us  to  build  a  TL  database  by  using  newly  developed 
PC  job  control  (batch  file)  procedures.  Also,  the  newly  acquired  Ethernet  technology  allowed  us  to 
communicate  rapidly  with  the  mainframe  computer  as  necessary  for  accessing  the  Navy-standard 
databases  and  for  building  output  delivery  files.  Numerous  PCs  now  process  the  TL  database  in 
large  blocks.  The  VAX  mainframe  computer  is  still  used  to  access  the  Navy-standard  environments 
and  to  package  the  completed  product  for  delivery.  Each  PC  is  programmed  to  run  node  after  node 
automatically  24  hours  a  day  (with  minimal  interruptions  to  collate  input  and  output).  This  carefully 
designed  procedure  has  allowed  us  to  closely  approach  our  goal  for  automating  the  range-dependent 
TL  database  building  process. 


6.0  PROCEDURES 
6.1  Planning  Charts 

Planning  charts  were  generated  by  contouring  DBDB5  data  with  an  Intergraph-workstation. 
Each  externally  indexed  subarea  chart  of  an  ocean  OPAREA  contains  bathymetric  contours  at 
200  m  intervals  with  an  overlay  grid  of  1 /4-degree  latitude  and  1/2-degree  longitude  resolution.  The 
files  were  printed  in  standard  Mercator  chart  format  at  NAVOCEANO.  The  sub-subarea  provinces 
are  determined  manually  in  the  manner  discussed  above  (Fig.  9).  Each  province  is  fit  to  the  overlay 
grid.  Individual  cells  of  the  grid  are  directly  mapped  to  the  province  they  overlay.  Figure  9  depicts 
the  grid  overlay  over  the  province  areas  A,  B,  and  C  of  Fig.  2,  thereby  defining  the  provinces 
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showing  the  individual  cell  compositions.  The  thick  boundary  lines  show  the  limits  of  the  provinces. 
All  cells  located  over  land  or  over  very  shallow  areas  (<100  m)  are  assigned  the  value  0000.  The 
first  two  characters  (C4  and  C5  of  the  node  name)  are  the  external  indexing  digits:  The  values  00 
indicate  land  or  shallow  water  in  all  ocean  OPAREAs  and  are  considered  out-of-bounds  for  this 
database. 

The  random  indexing  scheme  allows  as  many  as  100  asymmetrically  shaped  provinces  to  be 
designed  into  a  particular  subarea.  A  single  point  is  chosen  (usually  near  the  geometric  center)  to 
represent  the  entire  province.  Each  province  is  then  assigned  a  two-digit  internal  indexing  number 
(C6  and  C7  of  the  node  name).  Although  we  utilized  the  random  indexing  scheme,  we  assigned  the 
node  numbers  in  a  manner  that  approximated  a  deterministic  nomenclature  scheme  to  indicate 
relative  position  within  the  subarea.  The  number  55  indicates  that  a  node  is  located  approximately 
in  the  center  of  the  subarea;  00  indicates  a  relative  position  at  or  near  the  southwest  corner;  and 
99  indicates  a  relative  position  near  the  northeast  corner.  The  node  position  information 
(latitude/longitude)  is  then  used  to  create  the  numerous  input  decks  on  the  PC  as  described  below. 
Concurrently,  the  province  cells  are  manually  digitized  on  a  Macintosh  computer  using  Microsoft 
Excel  spreadsheet  software.  The  digitized  charts  are  transferred  to  the  VAX  and  PCs  to  create  the 
binary  files  that  can  be  accessed  by  the  finder  software  or  plotted. 

After  the  provinces  are  determined  and  the  maps  prepared,  the  Input  Deck  files  are  created 
(The  database  integration  overview  is  depicted  in  Figs.  10a  through  lOd).  The  Input  Deck  files 
contain  information  about  the  nodes  that  make  up  each  province  (Fig.  10a,  Process  2.0).  Each 
file  contains  node  numbers,  latitude  and  longitude  for  the  given  node  number,  wave  height,  depth. 
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(a) 


Fig.  10  —  (a)  TL  database  integration  procedure  overview  (level  1 ) 


A  Range-Dependent  Transmission  Loss  Database  Application 


23 


1S.0 


DIGrTlZED 

NODE 

DATA 


RUN 
BINARY 
FINDER 
SOFTWARE  I 
VJPCBNFFT) ) 


LAT/ 

LON 


NODE 

NUMBER 


CREATE 
NOOE 
FINDER 
INPUT 
FILE  (.N> 
(PCMK- 
-  MAP-)  - 


N*  NOOE.BIN 
FILE 


A 


STD 

FORMATTED 
NOOE  DATA 


t 


STD 


FORMATTED 

DATA 


BNARY 

MATRIX 

DATA 


WNOOEIN 

FILE 


STD 

FORMATTED 

DATA 


STD 

FORMATTED 
NOOE  DATA 


BINARY 
RECTAN¬ 
GULAR 
MATRIX 
J  DATA 


N*NOOE  BRM 
FILE 


LAT/ 

LON 


18.0 


CREATE 

BINARY 

OPAREA 

FILE 

(PC2BIW) 


NOOE 

NUMBER 


SHDPLT 

NPUT 

DATA 


NPLOT.BRM 

PLOT 

FILE 


17.0 


I 


PLOT  DATA 


RUN 
FINDER 
|  SOFTWARE 
(PCFIN*) 


21.0 


COLOR 

DATA 


CREATE 
OPAREA 
PICTURE 
USING 
SHDPLT  12 


PIXEL  OUTPUT  DATA 


□ 

SETUP  DAT 
FILE 

r 

PLOT  COL 

FILE 

OPAREA 
PIXEL  FILE 
C.PIX) 

Fig.  10  —  (b)  TL  procedure  overview  (level  1  continued) 
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Fig.  10  —  (c)  TL  procedure  overview  (level  1  continued) 
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Fig.  10  —  (d)  Run  PC  batch/software  jobstream  TL  procedure  overview  (level  2) 
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and  file  input  characters.  These  files  are  created  by  the  program  BLDINPUT.  Both  summer  and 
winter  season  files  are  created  for  each  province.  These  files  will  be  accessed  by  the 
batch/software  jobstream  to  create  EXT*. IN*  files;  by  the  SVPANA  software  in  the  creation  of  the 
Sound  Velocity  Profile  Analysis  file;  and  by  the  TSTDTH2  software  to  test  inputs  for  a  proper 
depth. 

6.2  Extracting  Environment  Databases 

The  database  information  is  extracted  after  the  ocean  OPAREAs  are  determined.  Using  INGRES/ 
EXTRACT  software  (Fig.  10a,  Process  3.0),  database  information  is  extracted  from  the 
Navy-standard  databases  (GDEM,  BLUG,  DBDB5  and  HFBL). 

Once  the  database  information  has  been  extracted  and  formatted  into  ASCII  data  files 
(Fig.  10a,  Process  4.0),  they  are  then  transferred,  via  Ethernet,  to  the  PC  ASCII  data  files.  The  data 
files  are  then  accessed  by  program  CREATEDB  in  the  creation  of  PC  databases  and  index  files 
(Fig.  10a,  Process  5.0).  The  database  and  index  files  will  be  accessed  by  the  batch/software  jobstream 
to  extract  acoustic  environment  data  to  be  used  in  the  creation  of  jobstream  output  files.  The 
SVPANA  software  will  also  extract  data  from  the  GDEM  database  and  index  files  to  produce 
the  SVPANA  file. 

6.3  Batch/Software  Jobstream  Processing 

6.3.  J  Setting  Up  Jobstream 

Batch/software  jobstreams  are  set  up  on  several  PC  workstations  to  run  nodes  in  the  various 
OPAREAs.  The  jobstream  input  files  (EXT*. IN*),  the  database/index  files,  and  the  batch  control 
run  file  (RUN*. BAT)  must  all  be  set  up  before  a  jobstream  can  be  started. 

The  jobstream  input  files  (EXT*. IN*)  are  created  by  MKEXTIN  (Fig.  lOd,  Process  6.1)  with 
data  from  the  Input  Deck  (.IN)  files  (Fig.  10a,  Process  2.0).  After  the  Input  Deck  (*.IN)  files  have 
been  created,  the  depths  are  tested  by  using  program  TSTDTH2  to  verify  that  they  are  correct  for 
extraction  from  the  environment  databases  (Fig.  10a,  Process  3.0).  The  database  files  are  set  up  on 
the  hard  drive  according  to  the  PC  workstation  configuration  (Fig.  lOd,  Process  6.2).  The  index 
files  are  modified  to  access  the  databases  on  the  hard-drive  and  stored  on  a  disk.  A  batch  control 
run-file  (RUN*. BAT)  is  set  up  from  a  generic  sample  file  (Fig.  lOd,  Process  6.3).  The  parameters 
within  this  user-prepared  control  file  are  modified  to  reflect  the  OPAREA  nodes  and 
the  PC  workstation  configuration.  Once  the  setup  files  are  complete,  RAM  must  be  set  for  the 
specific  PC  workstation  (Fig.  lOd,  Process  6.4).  BLDRAM.BAT  sets  up  the  RAM  disk  in  preparation 
for  processing  to  build  TL  databases. 

6.3.2  Jobstream  Execution 

Processing  is  started  by  initiating  the  batch  control  run-file,  RUN*. BAT.  The  parameters  for 
each  node  to  be  processed  are  passed  to  the  RNDNODE.BAT  (Fig.  lOd.  Process  6.6).  The 
RNDNODE.BAT  program,  in  turn,  controls  all  processing  for  the  current  node,  by  calling  the  remaining 
batch/program  software,  producing  at  the  end  of  a  successful  run  an  *.ARC  file  containing  the 
*.DAT,  *.BDA,  *.GEO,  and  *.PIX  output  files. 

The  EXTRAST  program  (Fig.  lOd,  Process  6.7)  is  called,  first  to  create  a  series  of  ASTRAL 
model  input  files,  by  extracting  from  the  set  databases  (GDEM,  BLUG,  DBDB5,  AND  HIFREQ) 
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along  a  great  circle  path  radial  track.  It  also  takes  inputs  from  the  EXT*. IN*  files  created  earlier 
by  MKEXTIN.  This  program  generates  a  track  for  each  radial  from  a  point  (36  radials  using  a 
10°  increment).  For  each  radial,  6  F_S_R.*  (frequency-source-receiver)  files  are  created  (Fig.  11) 
for  a  total  of  216  F_S_R.*  files  (36  radials  x  6  combinations)  allowing  the  execution  of  various 
combinations  of  frequencies,  source  depths,  and  receiver  depths. 

EXT2AST.BAT  (Fig.  lOd,  Process  6.8)  is  then  called  by  RNDNODE.  It  controls  processing  for 
each  ASTRAL  model  radial  created  by  EXTRAST.  EXT2AST  calls  RNDCZ.BAT,  the  program  that 
runs  the  ASTRAL  model  and  postprocesses  the  TL  table.  This  program  is  called  36  times  for  each 
point.  Postprocessing  of  ASTRAL  output  (Fig.  11)  in  this  program  consists  of  reformatting  the 
linear  interpolation  to  determine  the  TL  values  by  calling  TLINTP.  Program  COMBINE  is  called 
to  create  the  table  (file)  of  Range-TL  data  for  each  of  the  three  geometries  and  for  all  eight 
frequencies.  The  tables  (files)  are  then  “directed,”  concatenated,  into  MKBDA.IN,  thus  creating  a 
large  ASCII  data  file  that  holds  data  for  all  36  radials,  three  geometries,  and  eight  frequencies.  This 
data  file  is  later  renamed  and  archived  as  the  *.DAT  file.  The  data  in  this  file  is  copied  to  MK3.IN 
and  used  as  input  by  MKBDA. 

At  this  point  in  the  jobstream,  RNDNODE  calls  MKBDA  (Fig.  lOd,  Process  6.9).  MKBDA 
packs  the  ASCII  output  of  EXT2AST  into  a  binary  direct  access  (*.BDA)  formatted  file  for  rapid 
retrieval  of  the  data.  This  program  also  produces  an  ASCII  file  of  the  output  model  geometries 
(*.GEO). 

Once  the  *.BDA  file  has  been  created,  RNDNODE  calls  RNDPIX.BAT  (Fig.  lOd,  Process  6.10). 
RNDPIX  controls  the  processing  of  the  creation  of  the  table  pixel  files  (*.P1X).  This  program  calls 
MKTABFLS.BAT  eight  times  (number  of  frequencies)  for  each  of  the  three  geometries.  MKTABFLS 
then,  in  turn,  calls  BDA2TBL,  which  creates  a  (*.BRM)  file  for  each  geometry/frequency  combination 
and  outputs  a  combination  of  24  files.  BRMQP  is  called  by  RNDPIX  (Fig.  1 1)  to  read  the  24  *.BRM 
files  and  combines  them  into  one  *.BRM  file  for  use  by  SHDPLT12.  SHDPLT12  is  then  called  to 
generate  the  PIXEL  (*.PIX)  files  (Fig.  12). 

6.3.3  Postprocessing 

Throughout  the  jobstream  process,  the  output  files  that  have  been  created  are  stored  in  an 
output  archive  file.  The  archive  file  is  named  according  to  the  database  type,  OPAREA,  the  node 
number,  the  season  being  processed,  and  the  file  type  (*.ARC).  These  archive  files  are  then  used 
by  the  other  software  to  produce  output  for  delivery  (Fig.  10a,  Process  8.0)  and  also  for  Quality 
Control  (Fig.  10a,  Process  10.0). 

6.3.4  Grid  Pixel  Software 

The  grid  pixel  software  uses  the  *.BDA  file  created  during  the  jobstream  to  generate  grid  pixel 
files  (Fig.  10a,  Process  9.0).  This  software  produces  24-grid  pixel  files  (Fig.  13),  a  file  for  each  of 
the  three  geometries  and  eight  frequencies  combinations.  The  pixel  files  are  named  according  to  the 
ocean,  node  number,  season,  geometry,  and  frequency.  The  pixel  files  are  then  archived  to  be  used 
when  performing  quality  control/analysis  (Fig.  10a,  Process  10.0). 

6.3.5  Digitize  Charts 

The  node  OPAREAs  created  earlier  (see  Sec.  6.1)  are  digitized  manually  by  using  Microsoft 
Excel.  The  digitized  ASCII  files  (charts)  are  transferred  to  the  VAX  and  PCs  and  are  used  to  create 
files  that  are  plotted  and  accessed  by  the  node  locator  (FINDER)  software. 
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Fig.  1 1  —  Software  overview  PC  batch/software  jobstream  program  flow  diagram 


6.4  Quality  Analysis/Control 

Quality  control  analysis  (Fig.  10a,  Process  10.0)  is  performed  by  viewing  the  output  table  pixel 
files  (Fig.  12)  created  within  the  jobstream  and  also  by  viewing  the  grid  pixel  files 
(Figs.  3,  4,  and  13)  created  by  running  the  GRID  PIXEL  software.  By  viewing  these  various 
graphic  output  files,  the  TL  database  is  qualitatively  analyzed  for  gross  errors,  and  failures  are 
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easily  determined.  An  individual  table  picture  depicts  all  eight  frequencies  for  a  particular 
source/receiver  depth  geometry  (Fig.  12),  and  an  individual  grid  picture  displays  only  one  frequency 
in  radial  form  (Fig.  13).  All  of  these  graphics  can  be  plotted  as  hardcopy  or  viewed  on  screen  either 
individually  or  in  a  continuous  loop  (movie)  format  using  program  D1SGRAF2. 

7.0  SOFTWARE  OVERVIEW 

To  develop  the  NRaD  CMAS  database,  the  utility  processing  programs  listed  below  were 
developed,  coded,  and  utilized  for  this  project.  Products  that  are  used  on  the  VAX  computer  are 
identified  by  the  (VAX)  suffix  to  the  program  name. 

AST240  is  the  Navy-standard  range-dependent  passive  acoustic  TL  model. 

BDA2BRM  reformats  a  BDA  file  containing  all  frequencies  and  depth  geometries  to  a  particular 
depth  geometry  and  frequency  in  a  binary  rectangular  format  (BRM)  for  use  in  a  graphics  package. 

BDA2TBL  creates  a  *.BRM  file  for  each  geometry-frequency  combination  and  outputs  a 
combination  of  24  files  to  be  combined  into  one  *.BRM  file  by  BRMQP.EXE. 

BLDINPUT  creates  the  node  input  deck  files  ("'.IN).  These  files  contain  standard  node  information 
that  is  used  in  the  jobstream  setup  and  by  various  other  programs. 

BLDRAM  creates  the  necessary  directories  and  copies  the  files  needed  for  processing.  Part  of 
the  setup  process  for  running  the  NRaD  range-dependent  TL  processing  in  random  access  memory. 

BRMQP  reads  a  series  of  *.BRM  files  created  by  BDA2TBL  and  places  them  into  one  *.BRM 
file  to  be  used  by  SHDPLT12  to  display. 

COMBINE  produces  a  table/file  that  contains  outputs  of  two  different  ASTRAL  runs  using 
identical  depth  geometry,  but  two  different  sets  of  four  frequencies  per  run. 

CREATEDB  creates  a  data  set  direct  access  file  to  be  used  as  input  for  the  radial  extract 
program. 

DISGRAF2  is  a  graphics  display  engine  that  can  recall  saved  pixel  files  generated  by  SHDPLT12 
either  individually  or  in  a  continuous  movie  loop. 

EXT2AST  is  created  by  EXTRAST.  Coordinates  the  ASTRAL  model  runstream  as  determined 
in  the  node  input  menu  files  (RNDCZ.BAT).  Output  is  a  large  ASCII  file  containing  the  TL  values 
(♦.DAT). 

EXTRACT  (VAX)  accesses  and  retrieves  Navy-standard  database  information  using  the  relational 
database  management  system  software  (INGRES). 

EXTRAST  creates  a  series  of  ASTRAL  model  input  files  by  extracting  sound  speed,  BLUG  and 
HFBL  bottom  loss,  and  bottom  depth  along  great  circle  path  sections,  and  creates  the  runstream  file 
to  execute  the  ASTRAL. 


GEOFRQLP.BAT  is  a  batch  program  that  receives  the  specific  node  parameters  to  generate  a 
different  geometry  and  frequency  to  be  passed  to  MKGRDPIX.BAT. 
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GETRNO  is  used  by  GETSTL  and  GETRTL  to  compute  appropriate  record  number  in  the 
*.BDA  file. 

GETRTL  is  a  subroutine  to  get  the  entire  RADIAL  TL. 

GETSTL  is  a  subroutine  to  access  *.BDA  and  return  a  single  TL  value  from  a  radial. 

GETTL  (VAX)  is  a  routine  to  return  TL  information  for  a  particular  node  file. 

LL2NOD*  (VAX)  is  a  routine  to  return  the  node  number  for  a  particular  LAT/LON  within  the 
OPAREA  BRM. 

LLP2BRM*  (VAX)  creates  an  OPAREA  Binary  Direct  Access  file  (OPAREA  BRM)  file  used 
by  the  node  locator  subroutines. 

LLP2PLT*  creates  an  OPAREA  Binary  Direct  Access  (*.BRM)  plot  file.  This  file  will  be 
inputted  into  the  color  shading  plot  program  to  create  a  picture  of  the  OPAREA  Node  locations. 

MKBDA  (VAX)  packs  the  ASCII  output  transferred  from  the  PC  (*.DAT  file)  into  a  binary 
direct  access  (BDA)  formatted  file  for  rapid  retrieval  of  data. 

MKBDA  packs  the  ASCII  output  of  EXT2AST  into  a  binary  BDA  formatted  file  for  rapid 
retrieval  of  data  (*.BDA).  MKBDA  also  creates  an  ASCII  file  of  the  output  model  geometries 
(*.GEO). 

MKBRMPC  reformats  an  ASCII  digitized  chart  of  the  OPAREA  defining  the  limits  of  each 
node  subarea  into  a  BRM  form  to  be  read  by  the  node  locator  program. 

MKEXTIN  builds  the  individual  node  input  parameter  menu  files. 

MKGRDPIX.BAT  is  a  batch  program  that  takes  the  passed  parameters  and  creates  a  GRD/ 
PIX.PIX  file  for  a  specific  node,  geometry,  and  frequency. 

MKMAP*  (VAX)  creates  an  input  file  of  all  i,  j  node  assignments  for  a  particular  OPAREA. 
Output  is  an  ASCII  digitized  chart. 

MKTABFBLS  is  called  multiple  times  by  RNDPIX.BAT  to  run  BDA2TBL.EXE  in  creating  the 
*.BRM  file.  For  each  call,  the  command  line  replaceable  parameters  to  specify  the  geometry  and 
frequency  desired. 

PC2BIN*  creates  an  OPAREA  binary  file  (*.BIN)  for  the  PC.  This  file  is  created  per  request 
of  customer  and  will  be  used  by  the  PC  binary  node  locator  program. 

PCBNFR*  is  the  Binary  PC  node  FINDER  program.  This  routine  reads  a  binary  (*.BIN)  file 
to  return  a  node  number  for  a  particular  LAT/LON  within  a  specific  OPAREA. 

PCBRM*  creates  an  OPAREA  binary  rectangular  matrix  (*.BRM)  for  the  PC.  This  file  will  be 
use  I  by  the  PC  node  locator  (FINDER)  program  (PCFIND*). 
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PCFIND*  is  the  PC  Node  Finder  program;  returns  a  node  number  on  the  PC  for  a  particular 
LAT/LON  within  a  specific  OPAREA. 

PCMAP*  creates  a  PC  input  file  (*.IN)  in  standard  shade  plot  format  for  a  specific  ocean 
OPAREA.  This  OPAREA  input  file  will  be  used  to  create  a  PC  binary  rectangular  matrix  (*.BRM). 

PCPLT*  creates  an  OPAREA  binary  rectangular  matrix  (OPAREA  *.BRM)  plot  file  for  the  PC. 
This  file  is  inputted  into  the  color  shading  plot  program  to  create  a  picture  of  the  OPAREA  Node 
locations. 

RDCZAS  reformats  the  ASCII  TL  output  file  from  AST240  into  the  VAMPNET  standard 
output  format. 

RNDCZ  is  a  batch  file  that  coordinates  the  intricate  details  of  the  ASTRAL  model  and  output 
formatting  programs. 

RNDNODE.BAT  controls  all  the  processing  for  the  currently  running  node,  producing  an 
ARCHIVE  (ARC)  file  containing  the  ASCII  output  (DAT),  the  Binary  Direct  Access  (BDA)  formatted 
output,  model  geometry  (GEO)  and  pixel  file  (PIX)  outputs. 

RNDPIX  is  a  driver  program  to  create  Quality  Analysis  graphics  and  save  them  in  pixel  files 
that  can  be  displayed  at  a  later  date  for  quality  control  of  the  final  product.  Graphics  are  in  tabular 
format. 

RUN*.BAT  coordinates  the  execution  of  RNDNODE.BAT  for  each  node  point  in  the  OPAREA. 

RUNPIX  creates  individual  graphics  of  each  frequency  and  depth  geometry  in  RADIAL  format 
for  specialized  display. 

RUNPIX.BAT  is  a  setup  batch  program  for  the  GRD/PIX  jobstream.  It  is  edited  for  specific 
parameters,  then  passes  these  parameters  to  the  GEOFRQLP.BAT. 

SHDPL.T  (VAX)  is  a  color  or  contour  display  package  using  DISSPLA  routines  to  graphically 
display  an  i-by-j  binary  matrix  of  data. 

SHDPLT12  was  originally  developed  on  the  VAX  as  a  color  display  of  an  i-by-j  binary  matrix 
of  data.  The  PC  version  can  save  pixel  files  for  future  display. 

SVPANA  analyzes  the  starting  GDEM  sound  velocity  profile  producing  information  such  as 
sonic  layer  depth,  deep  sound  channel  axis,  critical  depth,  depth  excess  and  half-channel  conditions. 

TLINTP  uses  linear  interpolation  to  determine  the  TL  output  values  between  the  TL  input 
values  and  outputs  TL  at  the  desired  range  points. 

TSTDTH2  tests  the  program  EXTRAST  ability  to  extract  the  starting  environments  from  DBDB5 
and  GDEM  databases.  It  also  can  adjust  the  deep  depth  geometry  to  conform  to  near  bottom 
condition  (-10  m  less  than  bottom  depth)  in  shallow  node  locations. 
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8.0  RETRIEVAL  SOFTWARE 

8.1  Node  Locator  (FINDER)  Software 

This  software  operates  on  the  VAX  and  PC  computers.  The  digitized  ASCII  files  are  used  on 
both  VAX  and  PC  computers  to  generate  a  node  input  file  to  be  accessed  by  the  Node  Locator 
(FINDER)  Software.  The  FINDER  Software  and  other  associated  programs  are  modified  to  run  in 
each  ocean  area.  The  input  (*.IN)  file  is  created  by  running  PCMKMAP*  (Fig.  10b,  Process  15.0) 
on  the  PC,  and  MKMAP*  (Fig.  10c,  Process  22.0)  on  the  VAX. 

On  the  PC,  the  node  input  file  is  used  to  create  a  binary  rectangular  matrix  file  (*.BRM) 
(Fig.  10b,  Process  16.0).  The  *.BRM  file  is  accessed  while  running  the  FINDER  Software  (Fig.  10b, 
Process  17.0);  a  latitude  and  a  longitude  are  given  as  input,  an  a  node  number  is  returned  as  output. 
The  PC  node  input  file  is  used  to  create  a  binary  OPAREA  file,  *.BIN  (Fig.  10b,  Process  18.0).  The 
*.BIN  file  is  accessed  by  running  the  Binary  Finder  software  (PCBNFR*).  The  PCBNFR*  Finder 
software  runs  the  same  as  the  FINDER  software.  It  is  given  a  latitude  and  a  longitude  as  input;  it 
returns  a  node  number  as  output.  The  PC  node  input  file  is  also  used  in  the  creation  of 
the  OPAREA  picture  (Fig.  5)  file.  First,  a  binary  plot  file  (NPLOT.BRM)  is  created 
(Fig.  10b,  Process  20.0).  The  plot  file  is  then  used  as  input,  along  with  a  setup  data  file  and  a  plot 
color  file,  by  SHDPLT12  (Fig.  10b,  Process  21.0)  to  create  the  OPAREA  pixel  (*.PIX)  file. 

On  the  VAX,  the  node  input  file  is  used  to  create  a  VAX  Binary  Rectangular  Matrix  file 
(*.BRM),  (Fig.  10c,  Process  23.0).  The  *.BRM  file  is  accessed  by  the  VAX  FINDER  software 
(Fig.  10c,  Process  24.0).  The  VAX  FINDER  works  the  same  as  the  PC  FINDER.  The  node  input  file 
on  the  VAX  is  also  used  to  create  the  VAX  OPAREA  picture  (Fig.  5).  A  VAX  *.BRM  plot  file  is 
created  (Fig.  10c,  Process  25.0).  This  file,  along  with  a  setup  data  file  and  a  plot  color  file,  is  then 
used  by  the  VAX  SHDPLT  program  (Fig.  10c,  Process  26.0)  to  create  a  data  file  (POPFIL.DAT) 
that  in  turn  is  used  as  input  to  run  DISSPLA  (Fig.  10c,  Process  27.0)  that  creates  the  OPAREA 
picture  that  is  sent  to  the  screen  and  the  printer. 
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APPENDIX 


DESCRIPTION  OF  THE  APPLICATION  OF  RECIPROCITY 


Reciprocity  is  a  phenomenon  of  wave  propagation  that  is  usually  introduced  to  students  in 
undergraduate  physics  courses.  For  the  purposes  of  this  project,  the  concern  is  whether  or  not  model 
results  can  be  shown  to  reflect  the  principle  of  acoustic  reciprocity,  especially  since  all  numerical 
acoustic  models  contain  approximations.  It  is  accepted  practice  in  the  acoustic  modeling  commu¬ 
nity  to  use  this  technique  to  help  validate  models  (F.  Jensen  and  W.  Kuperman,  “Consistency  Test 
for  Acoustic  Propagation  Models,”  S  ACL  ANT  Center  Memo  SM-157,  March  1982).  The  technique 
involves  running  a  model  from  point  1  to  point  2,  then  running  the  model  from  point  2  to  point  1, 
then  comparing  the  output.  In  keeping  with  the  definition  of  reciprocity,  the  comparison  need  only 
match  at  the  range  equal  to  the  distance  between  points  1  and  2.  How  well  they  compare  is,  in  a 
sense,  a  measure  of  how  “good”  the  model  is.  It  would  be  more  accurate  to  say,  however,  that  a 
reciprocity  test  is  a  measure  of  how  consistent  the  model  treats  the  environment. 

There  are  important  qualifications  in  the  use  of  this  technique.  The  more  obvious  deals  with 
source/receiver  geometries.  Assume  in  the  initial  model  run  that  the  source  (at  point  1)  is  shallow 
and  that  the  receiver  (at  point  2)  is  deep.  When  making  the  model  run  in  the  reverse  direction,  the 
new  source  (at  point  2)  must  remain  deep,  and  the  new  receiver  (at  point  1)  must  remain  shallow. 
The  more  subtle  consideration  is  that  both  the  source  and  receiver  must  be  assumed  to  be 
omnidirectional. 

Given  that  this  technique  is  accepted  as  an  indicator  of  how  consistent  a  model  is,  studies 
demonstrating  how  well  particular  models  have  preserved  reciprocity  are  not  uncommon.  An  example 
is  an  article  by  T.  Nghiem-Phu  and  F.  Tappert  (“Modeling  of  reciprocity  in  the  time  domain  using 
the  parabolic  equation  method,”  J.  Acoust.  Soc.  Am.,  July  1985)  in  which  they  conclude  that  their 
results  confirm  that  the  PE  model  is  accurately  reciprocal.  A  similar  model  study  using  ASTRAL 
could  not  be  found.  (Recall  that  the  Navy-standard  ASTRAL  model  was  used  to  build  the  CMAS 
TL  database).  On  the  one  hand,  ASTRAL  has  the  reputation  of  being  a  high-speed  model  that  uses 
a  lot  of  approximations;  on  the  other,  the  internal  logic  of  the  model  mikes  specific  use  of  reciprocity. 
These  factors  suggest  that  a  model  study  investigating  reciprocity  with  ASTRAL  is  a  worthwhile 
endeavor. 

During  the  effort  to  construct  this  database  (which  would  require  millions  of  model  runs),  we 
knew  that  any  chance  to  be  more  efficient  was  worth  pursuing.  Given  that  even  the  simplest  of 
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simulations  should  include  depth  dependence  for  both  the  target  and  the  sensor,  four  was  the 
minimum  number  of  source-receiver  geometries  required: 

(1)  Shallow-Shallow  (SS) 

(2)  Shallow-Deep  (SD) 

(3)  Deep-Shallow  (DS) 

(4)  Deep-Deep  (DD) 

We  chose  to  run  the  first,  second,  and  fourth  geometries,  and  we  devised  a  way  to  represent 
the  DS  geometry  by  invoking  reciprocity  using  the  data  from  the  SD  case.  By  using  this  technique, 
we’ve  had  to  run  “only”  6  million  TL  calculations  instead  of  8  million. 

To  demonstrate  this  technique  we  selected  a  node  at  random.  Figure  A1  shows  our  sample  point 
(Node  32)  off  the  East  Coast  of  the  U.S.  The  CMAS  database  contains  files  for  that  node 
(as  it  does  for  every  other  node)  giving  TL  at  one  nautical  mile  increments  out  to  300  nmi  for 
36  radials.  (In  Figs.  A1  and  A2,  a  circle  with  a  300  nmi  radius  is  drawn.)  This  “wagon-wheel”  of 
data  is  repeated  for  the  three  selected  source-receiver  geometries  and  for  eight  frequencies. 
Figure  A2  depicts  the  other  40  nodes  that  are  within  300  nmi  of  Node  32. 

Let  us  set  a  scenario  where  an  OMNI  buoy  at  a  shallow  depth  is  located  at  the  same 
latitude/longitude  as  that  which  represents  Node  32.  Let  us  suppose  a  deep  target  is  75  nmi  to  the 
northwest  (and  that  its  latitude  and  longitude  are  the  same  as  Node  45).  The  TL  data  needed  for 
this  case  would  be  pulled  from  File  32,  second  (SD)  column.  If  the  OMNI  buoy  at  Node  32  was 
a  deep  sensor  and  the  target  75  nmi  to  the  northwest  was  a  shallow  target,  there  would  be  no 
corresponding  data  within  File  32.  Instead,  the  second  (SD)  column  in  File  45  (for  the  reciprocal 
bearing)  would  be  used  to  provide  the  data. 

No  particular  purpose  would  be  served  by  citing  the  TL  values  for  the  cases  just  described. 
They  need  not  match  because  these  are  not  reciprocal  cases.  The  SD  column  of  numbers  in  File  45 
would  need  to  be  compared  to  DS  numbers  from  Node  32.  And  these  are  precisely  the  numbers  that 
were  not  computed  (to  save  time/space  in  constructing  the  database). 

To  test  for  reciprocity  with  ASTRAL  using  this  CMAS  database,  we  would  have  to  use  the  data 
in  a  manner  for  which  they  were  not  intended.  Given  the  scenario  above,  this  time  we  would  fix 
the  sensor-target  depths  to  be  the  same  (i.e.,  SS  and  DD).  Keep  in  mind  that  this  is  for  the  purpose 
of  testing  ASTRAL’s  ability  to  preserve  reciprocity,  and  is  quite  different  from  using  reciprocity 
to  infer  TL  values  for  cases  that  have  not  been  computed. 

First,  we  list  the  TL  values  computed  from  Node  32  out  75  nmi  in  the  direction  of  Node  45 
(for  the  lowest  five  frequencies  only,  since  the  higher  frequencies  show  nothing  but  high  loss  at 
long  range).  We  compare  them  to  the  TL  values  from  Node  45  out  75  nmi  in  the  direction  of 
Node  32. 
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Depth  Geometry 

Frequency  (Hz) 

File  32  (dB) 

File  45  (dB) 

SS 

50 

97.5 

91.0 

150 

94.3 

94.9 

315 

101.0 

101.5 

630 

107.0 

109.5 

900 

113.9 

117.0 

DD 

50 

92.1 

92.0 

150 

91.3 

91.5 

315 

92.1 

92.5 

630 

95.0 

95.5 

900 

99.0 

99.5 

Most  of  the  comparisons  show  excellent  agreement  and  tend  to  support  the  idea  that  ASTRAL 
is  reciprocal.  The  SS  50-Hz  case,  however,  appears  to  be  a  poor  sample  case  for  reciprocity.  We 
reviewed  the  anomalous  cases  a  little  more  closely.  Aside  from  the  presence  of  “engineering  patches” 
in  ASTRAL  that  “fix”  perceived  weaknesses  in  the  model,  the  fact  that  ASTRAL  takes  fairly  long 
range  steps  while  computing  radial  TL  is  a  likely  cause  of  mismatches.  Relaxing  our  criteria  in  that 
dimension,  we  find  that  less  than  2  nmi  away  these  two  TL  curves  intersect.  This  greatly  influences 
our  criteria  for  determining  if/when  the  comparisons  support  the  idea  that  ASTRAL  is  reciprocal. 

With  five  frequencies,  two  geometries,  and  40  nodes  within  300  nmi  of  Node  32,  our  sample 
set  contained  400  comparisons.  For  some  of  them,  the  comparisons  were  at  such  a  distance  that  the 
TL  curves  had  already  hit  the  arbitrary  “floor”  of  150  dB.  Twenty-five  cases  of  this  type  were 
removed  from  the  sample  set.  The  remaining  375  were  graded  on  how  close  they  compared  (1)  in 
decibel  space  at  the  range  equal  to  the  distance  between  nodes,  and/or  (2)  in  nautical  miles  distant 
from  that  range  to  where  the  TL  curves  intersected.  Figure  A3  reveals  that  ASTRAL  achieves  an 
excellent  score  on  this  test.  Describing  the  axes  in  other  terms,  we  can  say  that,  on  this  test  (which 
is  not  a  particularly  easy  test  considering  the  bathymetric  relief).  51%  of  the  class  received  an  A; 
20%  got  a  B;  15%  got  a  C.  These  numbers  are  impressive  (86%  within  3  dB).  On  the  borderline, 
9%  got  a  D;  4%  received  a  D  minus.  Only  1%  failed  the  reciprocity  test. 

Two  results  were  achieved  by  this  effort.  First,  the  anomalous  cases  can  now  be  easily  identified. 
After  bringing  these  to  the  attention  of  the  ASTRAL  model  developers,  further  improvements  may 
be  forthcoming.  Second,  the  success  of  this  study  influences  future  design.  Reciprocity  may  be  a 
“permanent”  feature  of  this  database. 


Fig.  A3  —  Reciprocity  categories  =  375 
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